## Context

This is just a pre-requisite to consolidating the project creation UI as
there's another page that has the project creation flow too
[here](https://github.com/supabase/supabase/blob/master/apps/studio/pages/integrations/vercel/%5Bslug%5D/deploy-button/new-project.tsx).
So the next step will just be to use the same `ProjectCreationForm`
there

No functional changes here - just moving things around

## To test
- [ ] Verify that project creation still works



<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit

* **New Features**
* Added a full “create project” experience with eligibility-aware
defaults, advanced configuration sections, optional GitHub integration,
and compute-cost confirmation when applicable.
* **Improvements**
  * Enhanced project-creation success/error handling and navigation.
* Refined CLI backup/restore dialogs (better layout/wording,
accessibility updates, and improved section separation).
* **Documentation**
* Standardized all relevant documentation links across the app using a
shared `DOCS_URL` source.
* **Refactor**
* Refactored the “New Project” page to delegate the wizard UI and flow
to a reusable creation component.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->

Co-authored-by: Miranda Limonczenko <miranda.limonczenko@supabase.io>

## Summary
- The unified log inspection point-lookup (`getUnifiedLogInspection` in
`apps/studio/data/logs/unified-log-inspection-query.ts`, used by
`ServiceFlowPanel` when a user selects a row to view its detail panel)
previously reused the whole selected search date range for its
`iso_timestamp_start`/`iso_timestamp_end` bounds, even though it looks
up exactly one row by `id`. With a wide search range selected
(days/weeks), this scans far more of the ClickHouse-backed `logs` table
than necessary.
- Since the selected row's own timestamp is already known client-side,
the query now bounds itself to a ±1 hour window around that timestamp
instead, falling back to the previous search-range behavior when no
timestamp is available.
- No SQL text changes for the time bound — the
`iso_timestamp_start`/`iso_timestamp_end` params are the existing
mechanism by which every other query in this file (and sibling logs
queries) bounds time server-side, so this follows that same convention
rather than adding a redundant inline `WHERE timestamp` clause.
- Also added an explicit `AND source = '...'` filter to the OTEL
point-lookup SQL. The logs table's primary key is `(project, source,
timestamp)`, so filtering on `source` narrows the sorted range before
the timestamp bound even applies — the service flow `type` already maps
1:1 to a `source` value, so no new data was needed at the call site.

## Test plan
- [ ] Typecheck (couldn't run locally in this environment — no
`node_modules` installed)
- [ ] Manually verify in Studio: open Logs Explorer with a wide time
range (e.g. 7 days), select a log row, confirm the detail/service-flow
panel still loads the correct enriched data
- [ ] Confirm behavior is unchanged when `logTimestampMs` is unavailable
(falls back to search range)

🤖 Generated with [Claude Code](https://claude.com/claude-code)

<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit

* **Bug Fixes**
* Improved unified log inspection accuracy by narrowing the inspection
window to ±1 minute around the selected log event when a timestamp is
available.
* Updated service-flow and OTEL inspection lookups to use the selected
log entry’s timestamp for tighter, more relevant results.
* Preserved the prior broader time-range behavior when a timestamp isn’t
available.
* **Refactor**
* Centralized log type → source mapping and generated the corresponding
query filters from that shared mapping for consistency.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->

## Context

In the table editor when hovering over a row that has fixed columns, the
wordings could appear like they're overlapping
<img width="339" height="95" alt="image"
src="https://github.com/user-attachments/assets/9de8252c-08fc-4dec-a2f2-21461e47691e"
/>

This is due to the `bg-surface-200` class that gets applied to rows on
hover which use alpha values, hence why it's happening. Opting to use
`bg-200` instead which doesn't have alpha values.

Also small fix for the copy button in `CodeBlock` as well which is
running into the same issue - opting to use a set of colors that doesn't
have alpha values instead.
<img width="127" height="115" alt="image"
src="https://github.com/user-attachments/assets/4d773474-49e0-4c3b-bea1-042ff3102f9c"
/>


<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit

* **Style**
* Updated table header, row hover, and selected-row background colors
for a more consistent appearance.
* Enhanced the code block copy button’s dark-mode and hover background
styling.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->